Hosted lists contain data from the dataset. They can also have their own data fields that are not shared among lists in the dataset, but belong exclusively to the list. Lists that do have their own fields will also have their own web subscription forms generated when the list is created. All the fields that appear in the dataset and in a particular list can be used as merged fields for messages sent to that list.
This screen is split into two frames. The left frame will display all the lists (if any) that belong to the open dataset. Datasets with many lists can use folders called “categories” to organize lists so that they are easier to find. See Section 8
Organizing Datasets for more information.
The right pane shows the actual overview of the dataset settings. Depending on the current user rights, the overview is displayed with two tabs (in case the logged-in user does not have access to the membership area layout customization) or three tabs, with access to the membership area layout customization using the Membership Area Layout tab. The settings overview displays the following details of the dataset:
The shared fields are fields that are common to the dataset and all lists in it. In other words, each list in the dataset has at least those fields defined for the whole dataset, and may optionally add its own fields to these shared fields. The fields are shown with their internal database name (also the merge-field name for that field) and, in parenthesis, their data type. Any mandatory fields are shown as bold. "Mandatory" means that members must fill out a value for these fields when joining the dataset.
Important: Once lists have been added to a dataset, some options for editing the dataset will be curtailed. Make sure the dataset is structured as desired before adding lists to it.
Similar to creating a dataset, creating a hosted recipient list is accomplished by using a wizard that guides you through the steps of designing the list and the accompanying web subscription form. To access this wizard, click
Dataset >
Create >
Create Hosted Recipient List from the Toolbar. The Hosted Recipient List Definition wizard opens and it is comprised of four main screens – General, Profile Fields, Profile Field Details, and Summary.
•
|
Name – This is the name of the mailing list. Subscribers will see this name for the list on the web form when they subscribe. LISTSERV Maestro users will see the name of the list in the default hosted list target group that is automatically created when the list is populated with subscribers. See Section 14 Creating Target Groups Based on a Hosted Recipient List for more details. Data administrators will see the list name in the dataset tree.
|
•
|
Internal Description – The internal description is seen by users working within the Maestro User Interface.
|
•
|
Public Description – The public description of the list appears on the subscription web form. If subscribers are permitted to select the lists they want to join and can view and change their subscription settings, having accurate descriptions will help them accomplish those tasks.
|
The Profile Fields screen contains a list of the fields in the dataset. New fields can be added to the list. Any added list fields will
not be shared with the other lists in the dataset. To add a new field, click the
Add Field link.
•
|
Name – The name of the field as it will be used internally by the system for mail merging and querying. Field names can only use upper and lower case letters A-Z and a-z, the numbers 0 – 9 and the underscore “_”. Spaces and other special characters are not allowed.
|
•
|
Display Name – The label that identifies the field on the web form. The display name will be seen by anyone accessing the list’s public subscription page on the Web. All alphanumeric characters are permitted, as well as spaces and most special characters.
|
•
|
Data Type – Choose the type of data to be entered in the field from the drop-down menu. Five different classifications of data are available:
|
•
|
Text – Text fields can accept any type of text, including dates in specific formats such as dd/mm/yyy or mm.dd.yyyy.
|
•
|
Number – Number fields accept any whole integers.
|
•
|
Boolean – Boolean fields are based on two states – true or false.
|
•
|
Single Select (lookup table) – A single selection field consists of a drop-down menu where one item from it may be chosen. It may also be represented as a set of option buttons.
|
•
|
Multiple Select (lookup table) – A multiple selection field consists of a drop-down menu where one or more items may be chosen. It may also be represented as a set of checkboxes.
|
•
|
Derived – When using single- or multi-select profile fields in a hosted recipient list (HRL), you can set up these two fields to be reliant on each other by using this profile field data type. A Derived profile field is determined from one or several other profile fields in the same list (the source fields). This is defined by a special derivation rule. The value of the derived field will be automatically calculated whenever the values of the source fields are changed. In addition, a derived field can only be a "Read Only" or "Hidden" field, which means that its value can not be entered directly.
|
•
|
Input Type – Decide whether the data is mandatory for subscribers to enter into the web form or optional. Optional fields can be designated as hidden or read-only if the subscribers are not allowed to enter or change the data in those fields. Boolean fields cannot be optional due to the nature of the data type – the selection equates to either true or false. Boolean fields may be visible or hidden.
|
After list fields are created, they can be edited, removed, moved up, or moved down by using the corresponding links on the right side of the table. Fields that are part of the dataset cannot be moved or edited from this screen.
The Profile Field Details screen has multiple tabs that allow you to toggle between the different settings for list profile fields. The number and type of tabs depends on the types of data fields added to the list.
The Selection Field Details tab only appears if there are profile fields of the Single Select or
Multiple Select type in the dataset or mailing list. In this case, for each of these fields, the lookup table must be specified that will be used to define the values that the subscriber may select from.
This tab displays the name of each such profile field together with a drop-down menu that contains all lookup tables that can be used together with the profile field. Select a lookup table from the drop-down menu to associate it with the corresponding profile field. The description of the selected lookup table appears beneath the drop-down menu so that the selected lookup table can be verified as the desired one. This step needs to be performed for each profile field that has one of the two types listed above.
Notes: This step needs to be performed for each profile field that has one of the two types listed above.It is possible to assign the same lookup table to several different profile fields (if that is desired).
Only lookup tables that are using the charset encoding "ASCII" or that are using the same charset encoding as was specified for the dataset (or in case of a list, the encoding that was specified for the dataset the list belongs to) can be selected.
For a dataset that already contains members or lists, or for a list that already contains subscribers, then the lookup tables assigned to the already existing profile fields can no longer be changed. If a new field is added to such a dataset or list (on the Profile Fields screen), then the lookup table for this new field can be assigned, but the lookup tables of the other fields still cannot be changed.
In addition, HRLs now have additional features available when creating and defining profile fields. If there are several single- or multiple-select fields defined on the Profile Fields page, of which at least one is a single-select field; then, when entering the Selection Field Details on the Profile Field Details page, the second drop-down menu will have the additional option of
<Depends on other field>. This option allows you to dynamically change the lookup table subset that is displayed by the profile field, depending on the user choice in another (single-select) profile field.
With this new option, you’ll need to tell the system how this dependency will be defined. To do so, click on the
Define link that appears right below the third drop-down menu once you have selected a source field name. (This will be an
Edit link if you’ve previously defined the dependency.)
This link opens the Dependency Mapping screen where you can define the dependency mapping between the values of the selected source field and the subset that is to be displayed by the profile field for which you are currently defining the settings. The screen shows a table where each possible value in the source field (which is always a single-select field) is displayed in the left column. The right column displays an associated drop-down menu for each value. For any given value, the selection in the drop-down menu defines which lookup table subset shall be displayed by the profile field, if the associated value from the left column is selected in the source field. The available choices are:
•
|
<Empty List> – If selected, then the profile field will display an empty list, if the associated value is selected in the source field.
|
•
|
<Full List of Values> – If selected, then the profile field will display the full list of lookup table values (i.e. no subset, but all values), if the associated value is selected in the source field.
|
•
|
Any Subset Name – If one of the subset names is selected, then the profile field will display only the lookup table values that are elements in this subset, if the associated value is selected in the source field.
|
Once you have defined the dependency mapping, click [OK] to close the screen and save your changes, or click
[Cancel] to close the screen without saving.
If a Derived profile field is added on the Profile Fields page of the Hosted Recipient List Definition wizard, then the Profile Fields Details page will contain a new Derivation Rules tab. These rules must be supplied for each field and define how the value for the derived field will be determined.
To define, click on the associated Define or
Edit link. This opens the Derivation Rule screen. Depending on your profile fields, you may have one or two options available to define the derivation rule. If you have two options, then the screen will display two radio buttons that allow you to choose between the two options. Once you have selected an option, you can then provide the details for that option.
Note: Only the single-select fields that are defined in the same object as the derived profile field are available in the
Mirror value of field drop-down menu. This means that if the derived field is a dataset field, then it can only reference a single-select field that is also defined in that dataset. If the derived field is a field of a hosted list, then it can only reference a single-select field in the same hosted list. It can not reference a single-select field from the dataset the hosted list resides in.
•
|
Calculate value with the formula below – This option is always available. Simply enter the calculation formula that will be evaluated to determine the value for the derived profile field. This can be any kind of formula, using all the formula features that are available.
|
The formula can be a constant formula, which would mean that all subscribers will have the same value in this derived profile field. However, a formula as a derivation rule is most useful if it is (at least partially) based on other profile fields, meaning that it is not constant. In such a case, each subscriber will have an individual value in the derived profile field (although not necessarily a unique value), as the formula is individually calculated based on the values of his profile fields.
Note: In the formula, you can only reference other profile fields that are defined in the same object as the derived field itself. This means that a formula of a derived field in a dataset can only reference other fields from the same dataset. It can not reference fields from any lists in the dataset. And, a formula of a derived field in a hosted list can only reference other fields from the same hosted list. It can not reference fields from the dataset the list resides in or fields from other hosted lists. However, a derived field can reference other derived fields as long as this does not create an endless recursion of references (i.e. a chain like "DERIVED1 references DERIVED2 references DERIVED3 etc." is possible; a recursion like "DERIVED1 references DERIVED2 references DERIVED1" is not possible).
When you are finished editing the derivation rule, click [OK] to save your changes, or click
[Cancel] to close without saving.
Derived fields require additional storage space in the system database and additional processing power by the server when their values are calculated. Because of this, a derived field should only be used if there is actually a need for it. Some situations where a derived field seems like a solution can actually be solved without a derived field; in which case, this other solution should be used.
You should also be aware that you can always add an additional derived field to an already existing dataset or hosted list, even if there are already members in the dataset or subscribers on the list. Therefore, you should usually refrain from creating a certain derived field if you have any doubts about whether or not your will actually be using this field. Instead, you should only add it once it turns out that you actually require it.
A derived field is the correct solution for the following situations:
•
|
Include Field in Subscriber Profile – The value of the derived field will appear as a visible value in the subscriber profile so that the subscriber can view this value on the corresponding profile page in the membership area.
|
•
|
Include Field in Tracking Reports – The derived field will be available in the Recipient Details tracking report (for a job with either personal or anonymous tracking).
|
For example, a derived field that extracts the domain name from the subscriber's email address would allow a tracking report that can show you how many recipients clicked on a certain link (or opened the email, etc.), broken down by recipient domains. For this, usually a "hidden" derived field is the correct choice (although you can also use a "read-only" field, if you also want to display the value in the subscriber profile, see above).
•
|
Include Field on Browse/Edit Screen – The derived field will be included in the subscribers list on the Browse/Edit screen, so that you can see the various values there, and also filter the list over these values.
|
In contrast, a derived field is usually not the correct solution for the following situations:
•
|
Mail Merging – A certain derived value will be included as a merge value in the body of a mail message. For this, you should not use a derived field (unless you need the derived field for other situations, see above).
|
Instead, simply include a *Calc system drop-in in your mail message, with the same calculation formula that you would have used for the derived field.
•
|
Target Group Condition Tree – A certain derived value will be used to filter the recipients in the condition tree of a target group. For this, you should not use a derived field (unless you need the derived field for other situations, see above).
|
This Input Validation tab only appears if there are any profile fields of the Text type (other than the
EMAIL column of the dataset) or the
Number type in the dataset or mailing list. In this case, the tab allows for optionally defining additional input validation rules for each of these fields. The tab displays the name of each such profile field together with a drop-down menu containing the possible input validation types.
•
|
Accept all values – No validation will be applied, all text input is valid (with a maximum length of 100, which is imposed by LISTSERV Maestro). Note that for some encodings, like UTF-8 or asian language encodings, the maximum character length may even be less than 100, depending on the specified value.
|
•
|
Date with format – Input will be validated as a date (day, month, and year) according to the date format specified. For the date format, four different formats are available:
|
•
|
yyyy-mm-dd – Year, followed by month, followed by day, separated by a hyphen.
|
•
|
mm/dd/yyyy – Month, followed by day, followed by year, separated by a slash.
|
•
|
dd/mm/yyyy – Day, followed by month, followed by year, separated by a slash.
|
•
|
dd.mm.yyyy – Day, followed by month, followed by year, separated by a dot.
|
•
|
Full Name – Input will only be accepted if it can be interpreted as a valid "Full Name", meaning a first name followed by a last name. To fulfill this requirement, the input must consists of at least two text strings separated by at least one space character. Examples for valid "Full Names" include: "John Doe", "Frank N. Furter", "Dr. Dolittle" but also "a b".
|
•
|
String length range – Text input will be validated so that the entered text is no shorter than the supplied minimum length and no longer than the supplied maximum length. Minimum and maximum length can both be the same value, in which case the entered text must have exactly the given length. Any input that does not fall into the given length range is not accepted. The given minimum must be 1 or more, the given maximum must be 100 or less, and the maximum must not be less than the minimum. Note that for an optional field an empty input is also accepted.
|
•
|
String length minimum – Text input will be validated so that the entered text is no shorter than the supplied minimum length. Any input that is less than this value is not accepted. The given minimum must be between 1 and 100 (including). Note that for an optional field an empty input is also accepted.
|
•
|
String length maximum – Text input will be validated so that the entered text is no longer than the supplied maximum length. Any input that is greater than this value is not accepted. The given maximum must be between 1 and 100 (including). Note that for an optional field an empty input is also accepted.
|
•
|
Accept all values – No validation will be applied, all number input is valid (in the range of -9223372036854775808 to 9223372036854775807, which is imposed by LISTSERV Maestro).
|
•
|
Number range – Number input will be validated so that the entered number is not less than the supplied minimum and not greater than the supplied maximum. Any input that does not fall into the given range is not accepted. The given minimum must be less than the given maximum. Note that for an optional field an empty input is also accepted.
|
•
|
Number minimum – Number input will be validated so that the entered number is not less than the supplied minimum. Any input that is less than the minimum is not accepted. Note that for an optional field an empty input is also accepted.
|
•
|
Number maximum – Number input will be validated so that the entered number is not greater than the supplied maximum. Any input that is greater than the maximum is not accepted. Note that for an optional field an empty input is also accepted.
|
Note: For a dataset that already contains members or lists, or for a list which already contains subscribers, then the input validation of already existing profile fields can no longer be changed. If a new field is added to such a dataset or list (on the Profile Fields page), then the input validation for this new field can be defined, but the input validation of the other fields still cannot be changed.
The Subscriber Name Definition tab only appears if there is at least one profile field of Text type defined (other than the
EMAIL field of the dataset) either in the profile fields of the hosted recipient list or in the shared profile fields of the dataset.
This tab also allows you to define what value to use as the recipient name in the To field of all mailings to this hosted recipient list. The value that is to be used as the recipient name can be a single
Text type profile field (containing the recipient's name), or it can be a combination of several
Text or
Single Select type profile fields (but at least one
Text field). If a combination of several fields is used, then they will be appended to each other in the given order with a separating space between each. This is used to construct the actual recipient name to be used in the
To field.
If you have a FIRST_NAME field, a
LAST_NAME field, and a single select
Title field, then you might want to specify all three in the following order:
Note: If several fields are appended to construct the full name, then they are separated by a space. However, if one of the fields is optional and there is no value provided, then no additional space will be inserted; this means that, between two values in the full name, there will only ever be a single space (unless more spaces have been specified somewhere "inside" of a value).
To define a profile field to be included in the name definition, select it in the Profile Fields field (left selection box), then click
[->] to move the field into the
Name Fields field (right selection box). To again remove a profile field from the name definition, select it in the right box and click
[<-]. To change the ordering of the profile fields in the right selection box, select a field in the box and then click the
Move Up or
Move Down link.
The Default Values tab is only visible when modifying a dataset or list that already contains subscribers and additional profile fields on the Profile Fields screen have been added. In this case, it is necessary to define defaults for the new fields that will be used for the already existing subscribers.
This tab lists all fields that have been added. Each field has a Define link. Click the link to define the default value for the given field. (For fields of the
Single or
Multiple Select type, before the default can be defined, a lookup table must first be assigned on the Selection Field Details tab.)
If the field is of the Multiple Select type (or
"visible", which is a variation of
Mandatory), then a default will have to be supplied before leaving the wizard. For optional fields (or
"read-only" or
"hidden", which are variations of
Optional), then a default doesn't need to be supplied. If the default of such a field is left empty, then the empty value will be used for all existing subscribers.
Previously, the profile fields of a hosted list only had a “display text” attribute. Now, there is a
Description field where you can enter a longer description of the profile field. This description will appear on the subscriber pages where the display name is not meaningful enough for the subscriber.
To define this new field, click on the Field Description tab. Click the Edit link next to the field you’d like to add a description to. The Field Description screen opens. Enter a description for the field, making sure that it explains what the subscriber needs to do to fulfill the field requirements.
The Summary screen displays all of the settings for the list. You can set the access level for the list by selecting one of the options in the
Public List Access drop-down menu. Lists that are
Open to everyone can be subscribed to from the dataset web form or the list web form. Anyone with the URL to either form can access the list subscription page. Lists that have
Access for subscribers only are visible to subscribers who have been added to the list by the data Administrator. The list will not be displayed on the dataset web form when accessed by a non-subscriber. Lists with
No public access will not appear to non-subscribers or subscribers from the dataset web form. This setting can be used when a list is under construction to prevent anyone from signing up prematurely.
Use the [<- Back] button to return to the previous screen. Click
[Finish] to save the list and return to the Recipient Dataset Details screen. After a hosted recipient list has been added to the dataset, it will appear in the dataset tree in the left frame represented by this icon and accompanied by the list name.